7. Mail from/to the Internet

Since October 2004 a group of I2P users and postman operate a proxy system for email messages from and to the Internet. Original and retired contributors to the proxy services are: sugadude,jrandom, duck, pipi, mule. Special thanks to cervantes and welterde for providing MX relay facilities and helping to keep this service available on the Internet.

The following chapters aim to explain how sending mails to the Internet and receiving mails from the Internet is implemented, considering security and privacy concerns of I2P’s users as well as the administrative aspects of such a system. If you think we missed some very important issue in this concept, send a mail to postman@mail.i2p or join #mail.i2p on the I2PNet IRC Network.

1. Working with a pseudo-mailidentity

A pseudo-mailidentity is a system that tries to render any form of sender address forgery impossible. If a recipient receives a mail from a certain
address, he can be sure that it was sent by the user behind the mailaddress set in the Return-Path header line. Within the postman.i2p system the identity is created by simple measures:

  • SMTP authentication is enforced.

  • The AUTH login name must match the sender address used in the mail.

    • Every user can only use his OWN address as the Return-Path for an email. The postman.i2p system requires you to authenticate yourself for every mail sent, it does not make a difference whether the recipient is a @mail.i2p user or an Internet destination. smtp.postman.i2p supports the PLAIN and LOGIN mechanism for authentication – all modern mail clients are capable of SMTP authentication.

    While a sender can still forge the From: header address, he cannot change the Return-Path: line in the mail, since it’s inserted by the MTA.

    2. Basics on forwarding mail to the Internet

    Out-proxies and gateways to I2P services must be handled with care. Under all circumstances the anonymity of I2P service users must be
    guaranteed. Interacting with Internet communication partners has to be kept strictly separated from I2P internal communication.
    Content from the Internet needs to be sanitized before being offered to I2P users or clients. Content that is being sent to the Internet
    needs to be sanitized to protect I2P users/clients.

    At the moment we’re using a number of relays acting as official MX servers for the domain i2pmail.org.
    Those servers both work as incoming and outgoing servers. smtp.postman.i2p and the out-proxy systems communicate solely by using I2P.

    The following happens when your mail is sent to the Internet:

    I2P mail to the Internet: (assuming sender is jondoe@mail.i2p)

    1. User connects to smtp.postman.i2p via I2P
    2. User authenticates as John Doe (or relaying will not be allowed at all)
    3. smtp.postman.i2p checks if the sender address matches the log-in account (jondoe==jondoe?)
    4. smtp.postman.i2p checks the user’s recipient quota
    5. smtp.postman.i2p sanitizes mail headers
    6. smtp.postman.i2p accepts/queues the mail
    7. smtp.postman.i2p rewrites the Return-Path and From: address of the mail to jondoe@i2pmail.org
    8. smtp.postman.i2p connects to mx.i2pmail.org via I2P and relays the mail.
    9. mx.i2pmail.org sanitizes mail headers
    10. mx.i2pmail.org relays the mail to its Internet destination according to DNS/MX entries

      11. Note:Please note that user@mail.i2p is always used as the sender address. When mail is forwarded to the Internet it will be mangled to: user@i2pmail.org. If you intend to receive mails from the Internet for your postman account, you should always give the
      “official” address and not the internal one.

      3. Forwarding mail from the Internet

      The official in/out-proxies do not carry any important data about I2P mail users at all. Mail is sanitized and forwarded to the smtp.postman.i2p system via I2P. If the machines are raided and confiscated no trace leading to the postman.i2p system can be found (No IPs, no account data). The queue file system for the mailer might contain a few still unsent mails. To protect those the complete queue file system, the I2P installation and all MTA related data reside on a crypto file system. In a nutshell:

      1. The out-gateway does not host ANY mailboxes.
      2. The out-gateway does not locally store any information about which accounts exist
      3. The out-proxy does not know the IP of smtp.postman.i2p – it uses I2P to relay mail
      4. The out-proxy can be sacrificed without exposing any sensitive information about I2P users.

        5. Internet mail back to I2P (assuming recipient is jondoe@i2pmail.org)

        1. The sender transmits the mail to his configured relay
        2. The mail gets relayed to the Internet-gateway of the I2P mail service according to official MX records for the domain i2pmail.org
        3. mx.i2pmail.org checks ACLs and eventually accepts the mail
        4. mx.i2pmail.org sanitizes headers / queues the mail
        5. mx.i2pmail.org rewrites the To: / envelope recipient addresses to @mail.i2p
        6. mx.i2pmail.org contacts smtp.postman.i2p via I2P - mail gets forwarded.
        7. smtp.postman.i2p sanitizes/removes headers
        8. smtp.postman.i2p delivers the mail to the user’s mailbox


          9. 4. Configuration of delay for outgoing mails

          While the smtp.postman.i2p mailer protects users by applying one last level of header sanitisation, the fact that an e-mail is being sent to the Internet alone carries some kind of information that can be used to lower the level of anonymity: an email sent to the Internet means that the sender is connected to I2P at this very moment. For this reason, a delay is being applied to outgoing mails. You can chose between the following:

          • 0-delay: the mail is forwarded immediately to the Internet
          • defer-delay: mail-forwarding is delayed for a certain amount of time (between 2000-4000 seconds) depending on the mail system’s queue runner

          • batch-delay: the mail is held until a cronjob at 0:00/12:00 UTC triggers the delivery

            • The Date: header line is always rewritten when mail is being delayed. Users can configure the delay in the [ Manage Account ] area.

            Default is a defer-delay for all outgoing mail.

            5. Quota … What Quota?

            As much as mail communication to and from the Internet is appreciated among fellow I2P users – “fellow” spammers always looking for new and anonymous ways to spam effectively. To be honest, without any security measures the whole postman.i2p system would allow spammers to send large amounts of messages to the Internet – protected by the level of anonymity I2P offers all its users (and not only to those who aren’t spammers).

            Since the out-proxy is not supposed to be listed on every blacklist and the operator of the out-proxy certainly does not want to be sued for
            allowing spam to be sent using this system, a quota system has been created.

            1. Every I2P mail user has a daily “quota” that restricts the amount of mail he’s able to send to the Internet (local I2P mail is not restricted). This quota is not based on the number of mails sent, but based on the number of recipients that receive mail from an I2P user.
            2. The quota is 20 recipients/day for mails to be sent to the Internet. This means a user can send 20 mails to one recipient each, or 4 mails to 5 recipients each or 1 mail to 20 recipients. Every combination is possible as long as the number
              of recipients does not exceed 20 a day.
            3. Every night at 0:00 UTC, the quota is refreshed back to 20 recipients to spend.
            4. If a user needs more recipients he can purchase them through computing a hashcash token.
            5. Depending on the number of collision bits of the hashcash, the user can purchase another 20,40 or 80 recipients.
            6. The extra recipients expire after 24h. Recipients can not be accumulated. If they are not spent within a day they expire.
            7. Every hashcash token can only be used once to acquire extra accounts
            8. Every user can view/modify his quota with the help of a soon to be installed web interface
            9. A user cannot exceed his quota. The check will be done right within the SMTP session leading to a denial of recipients after each RCPT command that has a non-I2P recipient.

              10. The quota can be managed in the new
              [ Manage Quota ] Area.
              Go there to acquire extra accounts via hashcash as well.

              6. How to prevent spamming from the Internet?

              For now the following model is implemented:

              1. deny incoming mails where the sanity/validity check of the SMTP session fails
              2. deny incoming mails from unknown domains
              3. deny incoming mails from domains with private network addresses NS/MX entries
              4. deny incoming mails from unknown/unaccepted senders (for a handful of usual suspect domains)
              5. deny incoming mails that are listed on certain blacklists
              6. gray-list mails
              7. accept the rest